Governments and other institutions, as users of networked computing systems, understand the value of security in protecting data from unauthorized disclosure. Government organizations, in particular, have gone to great lengths to encrypt data for privacy and to strongly authenticate users, so that participants in data exchanges can be assured of the identities of their communications partners. Furthermore, many organizations have instituted highly compartmentalized, private networks with firewalls that are either hardware or software barriers that prevent outside users from accessing data inside the firewall.
One drawback to this “island” network security approach is that it complicates the sharing of data with legitimate users in other organizations. Current organizational and business models demand interactivity and interdependency on consultants, workers, and people in other partnering organizations beyond the firewall. All of these people must cooperate, and even collaborate, in their everyday operations to respond quickly to emerging opportunities and threats. Today, the need to traverse organizational boundaries is greater than ever. The result of this tension—between strong data protection on the one hand and the need to share data on the other—can create obstacles to collaboration. Many organizations circumvent security measures entirely, for instance, sending data as email that often is not secure. Others may simply take no action.
Many organizations take good faith, but haphazard, approaches to solving the problem of data accessibility. Some network administrators open ports in the firewall to allow access by outsiders using selected protocols. Other administrators institute virtual private networks (VPNs) that allow known remote workers to tunnel into specific systems inside the firewall.
Still other organizations establish one or more systems in a network area known as a DMZ (“demilitarized zone”). A DMZ lies outside the main firewall of an organization and is accessible to people inside and outside the organization. For example, web servers often reside in a DMZ.
One problem with these solutions is that they require significant involvement by network administrators. Further, once these systems are implemented, administrators are left with the burden of maintaining them. Solutions like these also place a high degree of responsibility and trust on the shoulders of administrative personnel. Disregarding the potential for administrative compromise, such solutions are often highly customized, and not well documented. If a person who establishes some customized solution leaves an organization, others may not know how the system is configured. This can lead to security holes in otherwise secure networks.
Another set of problems with these solutions is their vulnerability to failures and focused attacks. Data robustness, data availability and methods to securely authenticate fellow collaborators are prerequisites for a secure system. Regardless of the strength of cryptographic protection, information must be available on demand.
In order to avoid heavy reliance on IT administrators while still maintaining good security, secure peer-to-peer collaboration systems have been developed. One of these is the Groove collaboration system developed and marketed by Groove Networks, Inc., 100 Cummings Center Suite 535Q, Beverly, Mass. 019015 that is described in detail at http://www.groove.net. See also U.S. Pat. No. 6,446,113 B1. In this system, a collaborator can create an account that contains “identities.” An identity consists of a “cryptographic persona,” which is two cryptographic “key pairs,” each with a private and a public key. These keys are used to implement secure communications with other identities. Using an identity a collaborator can create ad-hoc collaborative places, called “shared spaces.” A shared space is effectively a shared area or a secure partition in the user's computer memory that other collaborators can access. Such a shared space can be created using the user interface that is part of the Groove collaboration system. The shared space could also be created in other manners such as by creating a file folder or another type of file sharing arrangement. “Shared space” as used herein means such a shared area no matter how it is created. A collaborator creating a shared space can then invite other members to join the shared space and introduce data and tools to the space. The Groove system uses standard web protocols so that it can communicate through a firewall without requiring network administrators to open special ports in the firewall. In addition, organizations can deploy Groove servers for centralized management, relay functions, integration and control over Groove usage.
In order to provide security, the Groove system automatically encrypts all user accounts, shared spaces, and their contents locally using 192-bit encryption. Furthermore, all content and activity within a shared space that is sent across the network is also encrypted and can only be decrypted by other members of the shared space. However, even though all communications are encrypted and integrity protected, data origin integrity can only be insured if the users can easily verify that the real-world people with which they are communicating are, and remain, the actual people with whom the users think they are communicating.
In order to do this the Groove system uses a process called authentication. This process involves comparing “digital fingerprints” of contacts. In particular, the Groove system automatically generates a unique and unambiguous digital fingerprint associated with each identity. A digital fingerprint is derived from the public keys of a contact and is presented to the user as a long, random-looking string of letters and numbers (with punctuation marks for readability). Two people can manually authenticate each other's identities by comparing the fingerprints they view for each other against the fingerprints they report to each other.
For example, suppose a first user invites a second user to join a shared space. The first user reports his or her fingerprint to the second user, and the second user checks the reported fingerprint against the fingerprint that is displayed when the second user opens the first user's contact information in the member panel. Then the first and the second user repeat this operation, this time with the first user manually authenticating the second user's fingerprint. It is also possible for “certification” to be performed by administrators in managed domains as described below.
However, even with the authentication procedure, it is still possible for unauthenticated communications to occur. This unreliability occurs because users do not take the time to perform the authentication process, thereby opening the system to spoofing and other attacks.